Date: Sat, 16 Oct 93 04:30:20 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 4#75 

To: Ham-Digital 


Ham-Digital Digest Sat, 16 Oct 93 Volume 93 : Issue 75 


Today's Topics: 
Public Apology (2 msgs) 
The header standard 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 15 Oct 1993 06:45:17 GMT 

From: koriel!sh.wide!wnoc-kyo!daemun.rcac! reseau! kenji@ames.arpa 
Subject: Public Apology 

To: ham-digital@ucsd.edu 


A host's sysop has the final words on what he/she wants to store on 
his/her systems. Period. 


// Kenji, JJ1BDX/3 
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp> 
"If privacy is outlawed, only outlaws will have privacy." 
-- Philip Zimmermann, PGP User's Guide 


Date: 15 Oct 1993 06:49:49 GMT 

From: swrinde!sdd.hp.com!spool.mu.edu!olivea! koriel!sh.wide!wnoc-kyo!daemun.rcac! 
reseau! kenji@network.ucsd.edu 

Subject: Public Apology 

To: ham-digital@ucsd.edu 


In article <2431@arrl.org> jbloom@arrl.org (Jon Bloom, KE3Z) writes: 
|Thanks for the update, Jack. Now I remember why I quit checking into the 
|local PBBS. It's interesting to see that the intellectual level of PBBS 
|traffic hasn't risen any. 


And it's sad to hear that it's not only in Japan that we have to see 
silly words on PBBSes :p 


// Kenji 


Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp> 
"If privacy is outlawed, only outlaws will have privacy." 
-- Philip Zimmermann, PGP User's Guide 


Date: Fri, 15 Oct 93 11:58:13 PDT 
From: almaden.ibm.com@uunet.uu.net 
Subject: The header standard 

To: ham-digital@ucsd.edu 


Here is the original header standard. The '$:' was added later 
after BIDs were invented :-) 


Roy, AAARE 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKAKK 


R:870114/0819p S:870114/1206p AA4RE-1, Gilroy, CA -- 4983/NK6K 
R:870113/1606 @:NK6K Redondo Beach, CA #: 4104 O:NK6K F:145.36/.01 


Headers - a compromise proposal. 

(1/13/87) 

Note: These comments are necessarily terse, to make them easier to 
forward. This proposal is based on input from VE3GYQ, W3IWI, 

NK6K, WB6KAJ, and WB6YMH. 


Executive summary. 
A standard header format is proposed that permits 1) machine 


parsable headers, 2) human readability, 3) extendability 
4) standard non-standard information. 


Why we need a standard. 


There are at least two programs waiting to be written that 
require a machine readable header. One is a subroutine for BBSes 
that can find the originating BBS and send a service message 
back. The other is a FWD.TNC file generator that can determine 
paths and connectivity by examining passing headers. There are 
more. 


There is also a desire on the part of sysops to be able to rapidly 
scan a message by eye to look for bad routing, loops, dups, and 
delays. This task could be done programatically, but won't be 
for some time to come, and will never be performed by simpler 
programs on smaller machines. 


Why the current standards are not sufficient. 


Aside from the Sent and Received times, the R:S: format as 
current specified does not provide an easy way to programatically 
determine the following pieces of information: Originating User, 
message number. These items have been stated as necessary by a 
number of BBS sysops. 


The /this/that/ standard does not provide enough visual fidelity 
to permit the eyeball scan to take place. This is the reason 
most often cited for the lack of converts to this standard. The 
other shortfall is the lack of ability to add regional 
information in a standard way. Some areas or networks want 
additional information such as frequencies and grid, areacode, 
airport, or other positional identifiers. In a fixed field 
format where the item is identified by its location, null fields 
would abound when handling several optional special items, e.g. 
/call/call/city/state/rtime////freq///stime/. 


As of late, there are at least three different versions of the 
/that/that/ "standard", one with an area code field, one with a 
separate state field, and one without either. This of course 
invalidates an otherwise acceptable standard due to its 
dependence on field order. 


Attributes of an acceptable standard. 
Based on the stated wishes of developers, the following are the 
requirements of a well-formed header: Each field can be 


identified by a program. Some fields are required. 


Based on the stated wishes of some Sysops/Users, the requirements 


are: the header is eyeball-readable, the individual sysop can 
add information to suit his local needs. 


Stated more formally: 


Meet FCC third party requirements (whatever they are) 

Be compatible with existing software (able to be emitted) 
Be machine readable (read: easy to parse) 

Provide all necessary information 

Provide flexibility for optional information 

Provide some degree of user friendliness (read: looks nice) 


DnoRWNHPR 


Note: These comments are necessarily terse, to make them easier to 
forward. This proposal is based on input from VE3GYQ, W3IWI, 
NK6K, WB6KAJ, and WB6YMH. 


The proposal. 


These requirements are not mutually exclusive. Rather than use 
the fixed field/positional style of the /this/that/ standard to 
meet the machine readable requirement, a field identifier is 
proposed for each field. Note that the R:S: standard is already 
close to this. The only thing lost over the /this/that/ format 
is some efficiency, more characters are sent. Losses of 
efficiency are common when humans are involved. 


Proposed header format (for the machine readable camp): 


<header line> ::= <header field> [<header field>...] 

<header field> ::= <field identifier> <field contents> 

<field identifier> ::= <field type> ':' 

<field type> ::= any printable ASCII character except ': 

<field contents> ::= a string of printable ASCII characters except ':' 
Rules: 

1. The ‘:' character may only be used as the termination 


character of a field type specifier 


2. The minimum items which should be included in ALL headers are: 
a) The callsign of the node relaying the message. 
b) The time the message was received. 


Items very (very) strongly recommended for all headers: 
a) the message number of the relaying node. 
b) the callsign of the station originating the message. 


c) the location of the node relaying the message. 


Optional information: 
a) Additional location information 
1. Grid squares 
2. Area codes 
3. longitude/latitude 
b) Frequency of operation of node 
c) time message was sent by node 
d) Network name 
e) group name 
£) Major maildrop (nearest major node) 


Field Identifiers: (Note new field types may be defined as 
required) 


d##: message number 


@: Node callsign followed by optional location 

A: node ALIAS 

F: frequency of operation. If gateway multiple frequencies are 
separated by "/" 

G: Grid square of node 

L: Long/Lat of node 

M: Major node callsign (nearest major relaying node, the APR 
proposal) 

N: Group, node, or network name 

0: callsign of originating station 

P: Telephone Area code of node 

R: Time message was received 

S: Time message was sent 


While many of the above fields may be deemed of value by 
different people the following suggested format is recommended 


R:861003/0739z @:W1BBS Packet city, KA #:1234 O:W1ABC 


Note if the timezone letter is not included it should be replaced 
with a space to preserve field alignment for visual fidelity. 


This header line provides the minimum information which is deemed 
necessary by large number of SYSOPs, based on current 
discussions. 


The proposed header format allows much flexibility for the 
individual sysop's without compromising the ability of software 
to extract the needed information. Following is an example of 
different headers which conform to this standard. Visual 
fidelity and machine readability is maintained. 


:861003/0701z @:KB3UD, East Bangor, Pa, G:FN20jv 
:861003/0641z @:K3RLI Wilkes-Barre, PA F:145.01/145.05 
:861003/0430 :N2AYY-1 Glens Falls, NY O:W1ABC 


:861002/1741z @:WB1IDSW O:W1ABC S:861002/2039z 
:861002/1523z @:W9ZRX #:8768 

:861001/1240 :WB6KAJ 

:861001/1836 :W6AXM-1 M:WB6KAJ O:W1ABC P:714 


AADAADA AAA A 


@ 
@ 
@ 
:861002/2040z @:WALFHB, Marlow NH #:5432 
@ 
@ 
@ 
@ 


Final Notes: The above differs from the current R:S: standard in 
that the S: field is missing from the first part. For visual 
fidelity to be maintained, all stations must agree to use the 
first two fields in that order. Those wishing to send the S: 
field may do so later in the header. Dropping the S: from the 
required fields is based on the premise that the S: field of a 
station can be inferred from the R: field of the next station. 


The RLI/MBL format for the minimum required format is: 
R:$3/$Kz @:$0 location #:$M 0:$P 
The "z" is replaced by a space if the BBS uses local time. 


End of Ham-Digital Digest V93 #75 
KKKKKKKKKKKKKKKKKKKKKEKKEKER KKK 


